System and method for cloud remediation of a client with a non-bootable storage medium

ABSTRACT

A remediation server receives a service request from a data processing device, the service request to diagnose a failure to load an operating system at the data processing device. A data storage device local to data processing device is identified, the data storage device storing the operating system. A diagnostic process is provided at the remediation server, the diagnostic process to mount the data storage device. A diagnostic service is performed based on information stored at the data storage device.

FIELD OF THE DISCLOSURE

This disclosure relates generally to information handling systems, andmore particularly relates to cloud remediation of a client informationhandling system with a non-bootable hard drive.

BACKGROUND

As the value and use of information continues to increase, individualsand businesses seek additional ways to process and store information.One option is an information handling system. An information handlingsystem generally processes, compiles, stores, and/or communicatesinformation or data for business, personal, or other purposes. Becausetechnology and information handling needs and requirements may varybetween different applications, information handling systems may alsovary regarding what information is handled, how the information ishandled, how much information is processed, stored, or communicated, andhow quickly and efficiently the information may be processed, stored, orcommunicated. The variations in information handling systems allow forinformation handling systems to be general or configured for a specificuser or specific use such as financial transaction processing,reservations, enterprise data storage, or global communications. Inaddition, information handling systems may include a variety of hardwareand software resources that may be configured to process, store, andcommunicate information and may include one or more computer systems,data storage systems, and networking systems.

BRIEF DESCRIPTION OF THE DRAWINGS

It will be appreciated that for simplicity and clarity of illustration,elements illustrated in the Figures have not necessarily been drawn toscale. For example, the dimensions of some of the elements areexaggerated relative to other elements. Embodiments incorporatingteachings of the present disclosure are shown and described with respectto the drawings presented herein, in which:

FIG. 1 is a block diagram of an information handling system according toan embodiment of the present disclosure;

FIG. 2 is a block diagram of an information handling system forproviding diagnostics and remediation according to another embodiment ofthe present disclosure;

FIG. 3 is a flow diagram illustrating a method for performing remoteremediation according to a specific embodiment of the presentdisclosure;

FIG. 4 is a flow diagram illustrating a method according to anotherembodiment of the present disclosure; and

FIG. 5 is a flow diagram illustrating a method according to yet anotherembodiment of the present disclosure; and

The use of the same reference symbols in different drawings indicatessimilar or identical items.

DETAILED DESCRIPTION OF DRAWINGS

The following description in combination with the Figures is provided toassist in understanding the teachings disclosed herein. The followingdiscussion will focus on specific implementations and embodiments of theteachings. This focus is provided to assist in describing the teachings,and should not be interpreted as a limitation on the scope orapplicability of the teachings. However, other teachings can certainlybe used in this application. The teachings can also be used in otherapplications, and with several different types of architectures, such asdistributed computing architectures, client/server architectures, ormiddleware server architectures and associated resources.

FIGS. 1-5 illustrate techniques for diagnosing and/or remedying bootfailures at an information handling system. In particular, firmware atan information handling system is configured to monitor processesresponsible for initializing execution of an operating system (OS), suchas a Windows operating system, a LINUX operating system, and the like.The OS is typically located on a storage device, such as a hard diskdrive, a solid state drive, or another type of data storage device. Afailure to initialize the OS can be referred to as a boot failure. Aboot failure can result from a corruption of a master boot record (MBR)or GUID partitioning table (GPT), misconfiguration of an extensiblefirmware interface (EFI) boot partition, corrupt Windows registry keysand values, malicious software, and the like. As disclosed herein, thefirmware can detect a boot failure, determine that the memory devicestoring the OS is accessible, and solicit assistance of a remedialservice resource located remotely from the information handling system.For example, the firmware can communicate with a remediation serverusing an Internet protocol. The remediation server can remotely mountthe data storage device containing the OS, and perform diagnostic testto determine the reason for the boot failure. If the remediation serveridentifies the cause of the failure, corrective actions can beadministered.

FIG. 1 illustrates an information handling system 100 including aprocessor 102, a memory 104, a northbridge/chipset 106, a PCI bus 108, auniversal serial bus (USB) controller 110, a USB 112, a keyboard devicecontroller 114, a mouse device controller 116, an ATA bus controller120, an ATA bus 122, a hard drive device controller 124, a compact diskread only memory (CD ROM) device controller 126, a video graphics array(VGA) device controller 130, a network interface controller (NIC) 140, awireless local area network (WLAN) controller 150, a serial peripheralinterface (SPI) bus 160, a non-volatile random access memory (NVRAM) 170for storing a basic input/output system (BIOS) 172, a trusted platformmodule (TPM) 180, and a baseboard management controller (BMC) 190.Information handling system 100 can include additional components andadditional busses, not shown for clarity. For example, system 100 caninclude multiple processor cores, audio devices, and the like. While aparticular arrangement of bus technologies and interconnections isillustrated for the purpose of example, one of skill will appreciatethat the techniques disclosed herein are applicable to other systemarchitectures. System 100 can include multiple CPUs and redundant buscontrollers. One ore more components can be integrated together. Forexample, portions of northbridge/chipset 106 can be integrated withinCPU 102.

For purpose of this disclosure information handling system 100 caninclude any instrumentality or aggregate of instrumentalities operableto compute, classify, process, transmit, receive, retrieve, originate,switch, store, display, manifest, detect, record, reproduce, handle, orutilize any form of information, intelligence, or data for business,scientific, control, entertainment, or other purposes. For example,information handling system 100 can be a personal computer, a laptopcomputer, a smart phone, a tablet device or other consumer electronicdevice, a network server, a network storage device, a switch, a router,or another network communication device, or any other suitable deviceand may vary in size, shape, performance, functionality, and price.Further, information handling system 100 can include processingresources for executing machine-executable code, such as CPU 102, aprogrammable logic array (PLA), an embedded device such as aSystem-on-a-Chip (SoC), or other control logic hardware. Informationhandling system 100 can also include one or more computer-readablemedium for storing machine-executable code, such as software or data.

BIOS 172 can be referred to as a firmware image, and the term BIOS isherein used interchangeably with the term firmware image, or simplyfirmware. BIOS 172 includes instructions executable by CPU 102 toinitialize and test the hardware components of system 100, and to load aboot loader or an operating system (OS) from a mass storage device. BIOS172 additionally provides an abstraction layer for the hardware, i.e. aconsistent way for application programs and operating systems tointeract with devices, such as a keyboard, a display, and otherinput/output devices. When power is first applied to informationhandling system 100, the system begins a sequence of initializationprocedures. During the initialization sequence, also referred to as aboot sequence, components of system 100 are configured and enabled foroperation, and device drivers can be installed. Device drivers providean interface through which other components of the system 100 cancommunicate with a corresponding device.

In an embodiment, the BIOS 172 can be substantially compliant with oneor more revisions of the UEFI specification. The UEFI standard replacesthe antiquated personal computer BIOS system found in some olderinformation handling systems. The UEFI specification provides standardinterfaces and interoperability guidelines for devices that togethermake up an information handling system. In particular, the UEFIspecification provides a standardized architecture and data structuresto manage initialization and configuration of devices, booting ofplatform resources, and passing of control to the operating system. TheUEFI specification allows for the extension of platform firmware byloading UEFI driver and UEFI application images. For example, anoriginal equipment manufacturer can include customized or proprietaryimages to provide enhanced control and management of the informationhandling system 100. While the techniques disclosed herein are describedin the context of a UEFI compliant system, one of skill will appreciatethat the disclosed systems and methods can be implemented atsubstantially any information handling system having firmware.

FIG. 2 is a block diagram of an information handling system 200 forproviding diagnostics and remediation according to another embodiment ofthe present disclosure. System 200 includes a personal computer 201 anda remote remediation server 210. Personal computer 201 includes a diskdrive 202, firmware 203, and a NIC 204. Disk drive 202 is configured tostore an OS 205. System 200 also includes a remediation server 210,which includes a NIC 211. Personal computer 201 and remediation server210 are configured to communicate over a network 220. In one embodiment,network 220 supports communication compliant with standard Internetprotocols. In addition, network 220 can include a wired network, awireless network, a local area network, a wide area network, acombination of such networks, and the like. For example, PC 201 cancommunicate with remediation server 210 over a Wi-Fi network provided byWLAN 150. In one embodiment, a wireless router or modem, not shown, canreceive wireless communications from WLAN 150 and propagate thecommunications to remediation server 210. In still another embodiment,network 220 can include a cellular telecommunications network.

Techniques disclosed herein are described in the context of a personalcomputer soliciting support from a remediation server, for example,resources provided by a service provider, an original equipmentmanufacturer (OEM), and the like. One of skill will appreciate thatthese techniques are applicable to any situation where firmware at aninformation handling system solicits diagnostic and remediation servicesfrom a remote entity to address a boot failure.

During operation, firmware 203 is configured to manage initialization ofpersonal computer 201. Under normal circumstances, the initializationculminates with passing control to an OS, such as a Windows operatingsystem. The OS software can be stored on disk drive 202, or another typeof storage medium, such as a solid state drive, a USB memory device, orthe like. For the purpose of the present example, the OS is stored ondisk drive 202, which is compliant with one or more formatting,partitioning, and file system standards, such as New Technology FileSystem (NTFS), master boot record (MBR), GUID Partition Table (GPT), andthe like. Disk drive 202 typically includes an indicator identifying thepresence of a bootable partition included on the drive. During an earlystage of device initialization, firmware 203 can identify disk drive202, determine that the drive contains an OS, and determine that thedrive is operating properly and can be accessed.

The OS and firmware are configured to monitor and report successful orunsuccessful launching of the OS. For example, the Windows operatingsystem specification provides a Simple Boot Flag (SBF) register to allowthe OS to notify firmware when a boot failure has occurred. During asubsequent boot attempt, the firmware can perform diagnostic routines totry to identify a reason for the previous boot failure. The SBFspecification specifies that a BOOTING indicator is initially set byfirmware 203, and is later reset by the OS to indicate the OS wassuccessfully loaded. During a subsequent boot operation at PC 201, suchas during a power-on self-test (POST), firmware 203 can access the SBFregister. If the BOOTING indicator is still set, firmware 203 candetermine that a prior attempt to load OS 205 was unsuccessful.

In one embodiment, one or more additional flags can be utilized tomaintain a strike count, indicating a number of successive bootfailures. For example, if a first boot operation failed due to atransient error, a subsequent attempt to boot OS 205 may be successful.Firmware 205 can include some diagnostic capabilities, but thesecapabilities may be limited, for example, by storage constraints ofNVRAM 170. It is not atypical that a boot failure at a personal computerresults in display of an error message informing a user of a problem. Inmany cases, a user of PC 201 will have little or no training to identifyor correct the problem. Typically, the extent of a user's capability mayinclude inserting an OS installation CD ROM, if available, andattempting to perform a repair operation provided by the OS installer.PC 201 may include resident diagnostic routines. For example, PC 201 mayinclude an alternate OS, such as a service OS, which may be stored atdisk drive 202 or at another data storage device. More often,remediation involves a service call, such as to the OEM, which can beinconvenient and costly. As disclosed herein, firmware 203 is configuredto establish communication with remediation server 210 over network 220.In one embodiment, remediation server 210 can gain access to disk drive202, remotely mount the drive, and diagnose the problem that ispreventing successful booting of PC 201.

FIG. 3 is a flow diagram illustrating a method 300 for performing remoteremediation according to a specific embodiment of the presentdisclosure. Method 300 begins at block 301 where an information handlingsystem identifies that a boot failure as occurred. For example, firmware203 at PC 201 can determine that a SBF is set, indicating that aprevious OS boot operation was unsuccessful. Furthermore, firmware 203can determine that disk drive 202 is accessible, at least from alow-level, hardware and electrical perspective. The method continues atblock 302 where the information handling system issues a network requestfor remedial services. For example, firmware executing at PC 201 cansend an Internet request to remote remediation server 210, requestingdiagnostic services. While system 200 illustrates so-called cloud-basedremediation server, one of skill will appreciate that remediation server210 can be provided geographically close to PC 201. For example,remediation server 210 can be connected to PC 201 by a local areanetwork (LAN). For another example, PC 201 can be a server at a datacenter and remediation server 210 can be local or remote to the datacenter, accessible over a LAN, by Internet, or via another standard orproprietary communications interface.

Method 300 continues at block 303 where the information handling systemprovides disk mount information to the remote remediation server. Forexample, remediation server 210 can utilize an Internet Small ComputerSystem Interface (iSCSI) to communicate with PC 201. ISCSI is anInternet Protocol (IP)-based storage standard typically used for linkingdata storage facilities. The protocol allows clients, called initiators,to send SCSI commands to SCSI storage devices, referred to as targets.ISCSI allows two hosts to negotiate and then exchange SCSI commandsusing IP networks to create a storage area network (SAN). PC 201 canprovide remediation server 210 with a logical unit number (LUN)identifying an individually addressable SCSI target device.

The method continues at block 304 where the remediation server, actingas an iSCSI initiator, remotely mounts the target data storage deviceand performs diagnostic and remedial services. For example, the iSCSItarget, at PC 201, can export the disk, or a file on the disk, as aniSCSI block device. The iSCSI initiator can then mount the exportedblock device. Because disk drive 202 is mounted as a block base device,information at the drive can be accessed independent of various filesystem architectures present at the drive. For example, the boot failuremay be caused by MBR corruption, and accessing data from drive 202 inblock mode allows remediation server 210 to identify the corruption.Block mode refers to accessing information stored at a storage device inunits of blocks, typically corresponding to one or more sectors. Blockaccess does not rely on high level formatting at the storage device,such as a NTFS, to be functioning properly. As used herein, a datastorage device accessed in block mode is referred to as a block device.

While the present example utilizes the iSCSI protocol to mount drive202, one of skill will appreciate that other virtual disk remote mounttechnologies can be employed that allow remediation server 210 toremotely mount drive 202. Furthermore, one or more standard orproprietary messaging protocols can be used to facilitate communicationbetween firmware applications at PC 201 and remediation server 210, suchas the Extensible Messaging and Presence Protocol (XMPP), Message QueueTelemetry Transport (MQTT), Advanced Message Queuing Protocol (AMQP),and the like. Method 300 can be entirely automated, thus not requiringintervention by a user of PC 201 or a technician associated withremediation server 210.

Method 300 continues at block 305 where a remediation log can be storedat the client system, the remediation server, or both. For example,remediation server can diagnose the cause of the boot failure, remedythe situation, and generate a log file enumerating the actions that wereperformed. In one embodiment, the log file can be stored at NVRAM 170.In particular, NVRAM 170 can include a predefined region that isreserved for storing such information. Furthermore, information storedat the predefined region of NVRAM 170 can be made accessible to firmware172 and to applications provided after an OS is successfully loaded.Method 300 proceeds to block 306 where the remediation server canun-mount the target storage device. Following completion of thediagnostic services, firmware at PC 201 can again attempt to boot theOS. If loading of the OS remains unsuccessful, method 300 can berepeated. If remote remediation fails to be successful, a service OS canbe invoked to provide further automated online service and support.

FIG. 4 is a flow diagram illustrating a method 400 according to anotherembodiment of the present disclosure. Method 400 is similar to method300, but described from the point of view of the remediation server 210.The method begins at block 401 where a remediation server listens forclient requests for support. For example, remediation server 210 canreceive a request from firmware executing at PC 201, the requestindicating that firmware has identified a boot failure that ispreventing an OS from being loaded. The method proceeds to block 402where the remediation server can request remote disk mount information,such as a LUN, as described above with reference to block 303 of FIG. 3.The method continues at block 403 where the remediation server mountsthe remote drive. For example, remediation server can utilize an iSCSIprotocol to virtually mount disk drive 202 at PC 201. The methodcontinues at block 404 where the remediation server performs diagnosticsand remedial services. For example, remediation server 210 can modifythe configuration disk drive 202, edit a Windows registry, and the like.At block 405, the remediation server can generate a log documenting thediagnostic activity performed, and store the log at one or both of PC201 and remediation server 210, or at another location. Method 400terminates at block 406 where the remediation server unmounts theclient's hard drive, thus completing the remote service call.

FIG. 5 is a flow diagram illustrating a method 500 according to yetanother embodiment of the present disclosure. Method 500 is similar tomethod 300, but describes an alternative embodiment where firmware 203does not include sufficient software resources necessary for remediationserver 210 to mount drive 202 and perform diagnostic actions. Forexample, NVRAM 170 may be limited in storage capacity. Therefore,software, such as iSCSI and other communications and diagnostic toolsmust first be downloaded to PC 201. The method begins at block 501 wherefirmware at an information handling system determines that one or moreboot failures as occurred. At block 502 firmware at the informationhandling system issues a request via the Internet or another networkcommunication medium, the request directed to a remediation server. Asdescribed above, the remediation server can be provided at an OEM oranother service provider that is tasked with providing support servicesto a client. A service that is provided remotely via the Internet isoften referred to as a cloud service.

At block 503, the remediation server transmits a runtime module to theinformation handling system, the runtime module including software tofacilitate remote mounting of the bootable storage device by theremediation server and for performing diagnostic tests. At block 504 theinformation handling system transmits disk mount information to theremediation server. At block 505, the remediation server mounts theclient's disk drive and performs diagnostic and remediation services, asdescribed above with reference to FIG. 3. Diagnostic tests can beperformed locally at PC 201 under the direction of remediation server210, by processes executing at remediation server 210, or at bothlocations. At block 506, a remediation log can be generated and storedat the client system, the remediation server, or both. At block 507 theremediation server unmounts the disk drive and the service call can beterminated.

Referring back to FIG. 1, the information handling system 100 caninclude a set of instructions that can be executed to cause theinformation handling system to perform any one or more of the methods orcomputer based functions disclosed herein. The information handlingsystem 100 may operate as a standalone device or may be connected toother computer systems or peripheral devices, such as by a network.

In a networked deployment, the information handling system 100 mayoperate in the capacity of a server or as a client user computer in aserver-client user network environment, or as a peer computer system ina peer-to-peer (or distributed) network environment. The informationhandling system 100 can also be implemented as or incorporated intovarious devices, such as a personal computer (PC), a tablet PC, aset-top box (STB), a personal digital assistant (PDA), a mobile device,a palmtop computer, a laptop computer, a desktop computer, acommunications device, a wireless telephone, a land-line telephone, acontrol system, a camera, a scanner, a facsimile machine, a printer, apager, a personal trusted device, a web appliance, a network router,switch or bridge, or any other machine capable of executing a set ofinstructions (sequential or otherwise) that specify actions to be takenby that machine. In a particular embodiment, the computer system 100 canbe implemented using electronic devices that provide voice, video ordata communication. Further, while a single information handling system100 is illustrated, the term “system” shall also be taken to include anycollection of systems or sub-systems that individually or jointlyexecute a set, or multiple sets, of instructions to perform one or morecomputer functions.

The information handling system 100 can include a disk drive unit andmay include a computer-readable medium, not shown in FIG. 1, in whichone or more sets of instructions, such as software, can be embedded.Further, the instructions may embody one or more of the methods or logicas described herein. In a particular embodiment, the instructions mayreside completely, or at least partially, within system memory 104 oranother memory included at system 100, and/or within the processor 102during execution by the information handling system 100. The systemmemory 104 and the processor 102 also may include computer-readablemedia. A network interface device (not shown at FIG. 1) can provideconnectivity to a network, e.g., a wide area network (WAN), a local areanetwork (LAN), or other network.

In an alternative embodiment, dedicated hardware implementations such asapplication specific integrated circuits, programmable logic arrays andother hardware devices can be constructed to implement one or more ofthe methods described herein. Applications that may include theapparatus and systems of various embodiments can broadly include avariety of electronic and computer systems. One or more embodimentsdescribed herein may implement functions using two or more specificinterconnected hardware modules or devices with related control and datasignals that can be communicated between and through the modules, or asportions of an application-specific integrated circuit. Accordingly, thepresent system encompasses software, firmware, and hardwareimplementations.

In accordance with various embodiments of the present disclosure, themethods described herein may be implemented by software programsexecutable by a computer system. Further, in an exemplary, non-limitedembodiment, implementations can include distributed processing,component/object distributed processing, and parallel processing.Alternatively, virtual computer system processing can be constructed toimplement one or more of the methods or functionality as describedherein.

The present disclosure contemplates a computer-readable medium thatincludes instructions or receives and executes instructions responsiveto a propagated signal; so that a device connected to a network cancommunicate voice, video or data over the network. Further, theinstructions may be transmitted or received over the network via thenetwork interface device.

While the computer-readable medium is shown to be a single medium, theterm “computer-readable medium” includes a single medium or multiplemedia, such as a centralized or distributed database, and/or associatedcaches and servers that store one or more sets of instructions. The term“computer-readable medium” shall also include any medium that is capableof storing, encoding or carrying a set of instructions for execution bya processor or that cause a computer system to perform any one or moreof the methods or operations disclosed herein.

In a particular non-limiting, exemplary embodiment, thecomputer-readable medium can include a solid-state memory such as amemory card or other package that houses one or more non-volatileread-only memories.

Further, the computer-readable medium can be a random access memory orother volatile re-writable memory. Additionally, the computer-readablemedium can include a magneto-optical or optical medium, such as a diskor tapes or other storage device to store information received viacarrier wave signals such as a signal communicated over a transmissionmedium. A digital file attachment to an e-mail or other self-containedinformation archive or set of archives may be considered a distributionmedium that is equivalent to a tangible storage medium. Accordingly, thedisclosure is considered to include any one or more of acomputer-readable medium or a distribution medium and other equivalentsand successor media, in which data or instructions may be stored.

Although only a few exemplary embodiments have been described in detailabove, those skilled in the art will readily appreciate that manymodifications are possible in the exemplary embodiments withoutmaterially departing from the novel teachings and advantages of theembodiments of the present disclosure. Accordingly, all suchmodifications are intended to be included within the scope of theembodiments of the present disclosure as defined in the followingclaims. In the claims, means-plus-function clauses are intended to coverthe structures described herein as performing the recited function andnot only structural equivalents, but also equivalent structures.

What is claimed is:
 1. A method comprising: receiving at a remediation server a service request from a data processing device located remotely from the remediation server, the service request to diagnose a failure to load an operating system at the data processing device; identifying at the remediation server a data storage device local to the data processing device, the data storage device storing the operating system; providing a diagnostic process at the remediation server, the diagnostic process to mount the data storage device; generating at the remediation server a software module including instructions executable by the data processing device to enable the remediation server to remotely mount the data storage device; providing the software module to the data processing device; mounting the data storage device over an Internet protocol compliant network; and performing a diagnostic service based on information stored at the data storage device.
 2. The method of claim 1, wherein the service request is generated by firmware at the data processing device during initialization of the data processing device.
 3. The method of claim 1, further comprising: generating a first request at the remediation server, the first request soliciting mount information from the data processor device; and receiving the mount information at the remediation server.
 4. The method of claim 1, further comprising generating a report documenting a result of the diagnostic service.
 5. The method of claim 1, further comprising mounting the data storage device using an Internet Small Computer System Interface.
 6. The method of claim 1, wherein the operating system failed to load twice in successive attempts.
 7. The method of claim 1, further comprising mounting the data storage device as a block device.
 8. A system comprising: a data processing device; and a remediation server located remotely from the data processing device, the remediation server communicatively coupled to the data processing device by a network, the remediation server to: receive a service request from the data processing device, the service request to diagnose a failure to load an operating system at the data processing device; identify a data storage device local to the data processing device, the data storage device storing the operating system; provide a diagnostic process at the remediation server, the diagnostic process to mount the data storage device; generate a software module including instructions executable by the data processing device to enable the remediation server to remotely mount the data storage device; provide the software module to the data processing device; mount the data storage device over an Internet protocol compliant network; and perform a diagnostic service based on information stored at the data storage device.
 9. The system of claim 8, wherein the service request is generated by firmware at the data processing device during initialization of the data processing device.
 10. The system of claim 8, wherein the remediation server is further to: generate a first request soliciting mount information from the data processor device; and receive the mount information from the data processing device.
 11. The system of claim 8, further comprising mounting the data storage device as a block device.
 12. A method comprising: identifying at a data processing device a failure to load an operating system, the operating system stored at a data storage device included at the data processing device; issuing a service request to a remediation server located remotely from the data processing device, the service request to determine a cause of the failure; receiving from the remediation server a software module including instructions executable by the data processing device to enable the remediation server to remotely mount the data storage device; receiving at the data processing device a request from the remediation server to remotely mount the data storage device to perform diagnostic services; enabling at the data processing device mounting of the data storage device over an Internet protocol compliant network by the remediation server; and receiving at the data processing device a diagnostic report from the remediation server documenting results of the diagnostic services.
 13. The method of claim 12, wherein the service request is generated by firmware at the data processing device during initialization of the data processing device.
 14. The method of claim 12, further comprising mounting the data storage device as a block device.
 15. The method of claim 12, further comprising: receiving a first request from the remediation server, the first request soliciting mount information from the data processor device; and providing the mount information to the remediation server. 